\section{Les connecteurs}
	Au niveau du modèle M2, un connecteur possède un objet 'Glue', ayant
pour objectif de lier les r\^ oles requis et fournis du connecteur.\\
	\subsection{Utilisation de la glue}
		\addcontentsline{toc}{subsection}{Sens de communication}
		\paragraph{\textit{Sens de communication : \\}}
			Cependant, en passant à l'impl\' ementation, au sein du modèle M1, un probl\` eme s'est posé, avec l'utilisation du pattern des observers : en effet, les glues observent les changements de valeurs des r\^ oles requis et des r\^ oles fournis, donc comment \' eviter une sorte de 'ping-pong' perp\' etuel entre les deux (Puisque, dans le cadre d'une transmission de donn\' ees, les deux vont \^ etres modifi\' es.) ?\\
			Pour r\' esoudre ce probl\` eme, nous avons d\^ u d\' ecoupler les connections de type r\^ ole requis - r\^ ole fournis de celles de type r\^ ole fournis - r\^ ole requis : ainsi, la glue observait soit le r\^ ole requis, soit le r\^ ole fournis.\\
			Mais cela a eu pour effet la cr\' eation de deux types de glue (Toutes deux instances de 'Glue', du mod\` ele M2) au niveau des connecteurs impl\' ement\' e (Il est d'ailleurs possible d'observer ceci au sein de la classe 'RPCGlue') : 'GlueIn()' et 'GlueOut()'.
		\addcontentsline{toc}{subsection}{Traitement}
		\paragraph{\textit{Traitement : \\}}
La glue est d\' efinie au sein du mod\` ele M2, et, comme le traiement entre chacun des r\^ oles \` a lier est sp\' ecifique \' a chaque connecteur, ce dernier est donc d\' efini au niveau du mod\` ele M1.\\
C'est donc pour cette raison que nous avons utilis\' e la r\' eflection java pour d\' efinir une m\' ethode, et donc un traiement particuli\' e au connecteur, pour ensuite l'injecter au sein de la glue \' a utiliser (Et qui donc d\'clenche la m\' ethode \'a l'aide d' 'invoke' lors de l'arriv\' ee d'une valeur dans le r\^ ole \' ecout\' e.).\\

